Chip 1996 April/CHIP 1996 aprilis (CD06).zip/CHIP_CD06.ISO/hypertxt.arj/9512/VACPP.CD

Text File | 1996-03-07 | 14KB | 228 lines

          @VIBM VisualAge C++@N

          @VOS/2 += C++;@N

              Elsô  pillantásra  is  komoly  vállalkozásnak  tûnik C++
          alapú vizuális fejlesztôrendszert  írni: valóban, a  feladat
          igen nehéz, hiszen  a C++ nem  kifejezetten támogatja azt  a
          dinamikus  megközelítést, amit  a legtöbb  objektumorientált
          kezelôfelület API esetében megszokhattunk.
              Sokan nem szeretik a C++-t. ïk kifejezetten  kételkednek
          abban,   hogy   ez  a   nyelv   alkalmas  komoly   feladatok
          megoldására.  Az  errôl  szóló  vitában  (aminek  színvonala
          egyébként  alig éri  el a  Commodore 64--ZX  Spectrum  hívôk
          között valaha dúlt csatározásokét) komoly érv a C++  mellett
          egy olyan jól megtervezett  rendszer, mint az IBM  VisualAge
          C++-a.


          @VErôforrás-igény@N

              Az elsô, ami a kérdéses termékkel kapcsolatban feltûnik,
          hatalmas merevlemez- és memóriaigénye.
              Nos,  igen. A  program majdnem  200 Mbyte-ot  foglal  el
          telepítés  után. Használatához  pedig 12,  illetve 16  Mbyte
          memória szükséges attól függôen, hogy a vizuális  eszközöket
          használjuk-e (16,  illetve 24  Mbyte ajánlott).  És még  sok
          memóriával  is  elég  lassú. Ez  egyfelôl  a  C++ jellegébôl
          adódik,  másfelôl  a   fordítóprogram  sajátossága.  Ezt   a
          problémát  sajnos   nem  lehet   megkerülni,  a   vele  járó
          kellemetlenségekért azonban kárpótol  bennünket az IBM  Open
          Class Library, a kellemesen megtervezett osztálykönyvtár. Az
          absztrakt  adatszerkezetektôl kezdve  az operációs  rendszer
          szolgáltatásainak  elérésére   szolgáló  osztályokon   át  a
          kezelôfelület-elemekig mindent megtalálunk benne.
              A VisualAge smalltalkos verziójára is jellemzô egyébként
          a  rendkívüli erôforrásigény,  mégis az  a véleményem,  hogy
          ezeknél a programoknál ebben a kategóriában szebb és  jobban
          megtervezett fejlesztôi környezet nem nagyon van. Az  IBM-re
          jellemzôen kevés a díszítôelem, a lényeges eszközök  azonban
          mind jól  használhatók (néha  persze csak  a szintén  az IBM
          termékeire jellemzô körülményességgel).
              A   VisualAge   C++-os   változata   alig   hasonlít   a
          smalltalkosra.   (A    VisualAge   Smalltalk    környezetrôl
          szeptemberi,  az   IBM  Smalltalkról   novemberi  számunkban
          írtunk.) Egyedül a vizuális alrendszer ismerhetô fel, de  az
          abban  használt  osztálykönyvtárak  már  más  jellegûek.  Ez
          persze    nyilvánvaló,    hiszen    az     osztálykönyvtárak
          felépítésénél tekintetbe kell venni  a nyelv jellegét is,  a
          Smalltalk és a C++ között pedig elég nagy a távolság.


          @VA rendszer alapja: a WorkFrame@N

              A két  rendszer közti  különbséget elôször  is az eltérô
          fordítási modell határozza meg. A VisualAge C++  rendszerben
          jóval lazább az eszközök közötti kapcsolat, mint a Smalltalk
          változatban,   ahol  tulajdonképpen   egyetlen  egy   valódi
          programba vonták  össze az  összes fejlesztôi  eszközt. (Más
          kérdés,   hogy   a   programot   több   logikai   folyamatra
          bonthattuk.) Itt az integráció  fô eszköze a WorkFrame,  egy
          olyan program, amelybôl a rendszer összes elemét elérhetjük.
              Egy  WorkFrame  project  tulajdonképpen  egy   speciális
          mappa,  amelyben  a  megvalósítandó  rendszer   komponenseit
          elhelyezhetjük, rajtuk bizonyos mûveleteket végrehajthatunk,
          illetve  ezeknek  a mûveleteknek  az  eredményét figyelemmel
          kísérhetjük.  Ez   gyakorlatilag  azt   jelenti,  hogy   egy
          WorkFrame project megnyitásakor  egy ablakot látunk,  amiben
          menü, két eszközsor (egy az ablak tetején, egy az alján)  és
          egy szöveges mezô van. A menüvel és az eszközsorokkal  lehet
          a  kiválasztott   file-okon  a   rendszer  többi   programja
          segítségével   mûveleteket   vérehajtani:    forrásfile-okat
          szerkeszteni,     a      programot     újrafordítani,      a
          böngészôprogramokat  elindítani.  Az  igen  csúnya,   sárga,
          szöveges mezôben  pedig mindenféle  információkat kapunk  az
          éppen  végrehajtott mûveletrôl.  (Ez programok  fordításakor
          több   oldalnyi,   igen   tanulságos   szöveg:   az  IBM-nél
          elképzelhetetlen,  hogy   megússzuk  olyanok   nélkül,  mint
          például ""Initializing actions hierarchy", esetleg ""Writing
          601 bytes  of module  format directive"  -- igazság  szerint
          nekem ez nagyon tetszik, bár elég hatásvadász.)
              Egy  érdekes,  a WorkFrame-bôl  elérhetô  opció a  Build
          Smarts. Ennek  segítségével az  egyébként kézzel,  egyenként
          megadható  fordítási  opciókat  állíthatjuk  át  egyszerûen,
          néhány  kattintással,  hogy  tartalmazzanak  más   speciális
          opciócsoportokat, például  a kód  optimalizálására vonatkozó
          vagy a böngészô program mûködéséhez szükséges beállításokat.
              Ehhez  kapcsolódóan  említésre méltó  program  a Project
          Smarts,  amivel  néhány  alapvetô alkalmazásosztály-mintából
          választhatunk, és amely -- a Borland C++-os Expertjeihez  és
          a  Microsoft   Wizardjaihoz  hasonlóan   --  létrehozza   az
          alkalmazás  keretét.  Ez  a  munkaasztalunkon  jelenik   meg
          ikonként, amit  megnyitva egy  WorkFrame projectet  érhetünk
          el.
              A  WorkFrame-bôl   elérhetô  legfontosabb   programok  a
          programozható  szövegszerkesztô,  a  vizuális  eszközök   (a
          Visual Builder), a nyomkövetô program, a  teljesítményelemzô
          program, a böngészô és a C++ fordító.


          @VA vizuális programozói környezet@N

              A VisualAge  C++ legérdekesebb  része a  Visual Builder.
          Ezzel  a  programmal tudunk  kattintgatással  új programokat
          létrehozni:  nincs más  dolgunk, mint  a megfelelô  részeket
          (kezelôfelület-elemeket, adatszerkezeteket stb.)  elhelyezni
          a megfelelô helyeken,  majd mindenféle nyilakkal  összekötni
          ôket.
              Egy kicsit részletesebben: a VisualAge környezeten belül
          a vizuális módszerekkel (egérrel) manipulálható objektumokat
          @Krész@Neknek  nevezzük.  Ezek  lehetnek  látható,  illetve  nem
          látható   részek   --   leggyakrabban  kezelôfelület-elemek,
          illetve adatszerkezetek. Egy @Krész@Nen végezhetünk mûveleteket,
          vannak   bizonyos   tulajdonságaik,   illetve  értesíthetnek
          bennünket  valamilyen eseményrôl.  Ennek megfelelôen  @Krész@Nek
          között a következô kapcsolattípusokat hozhatjuk létre:
              @V*@N  Tulajdonság--tulajdonság közti  kapcsolat: két  érték
          közötti  kapcsolat.  Ha  az  egyik  érték  megváltozik, vele
          változik a másik is.
              @V*@N    Esemény--tulajdonság    kapcsolat:    az    esemény
          bekövetkezte a tulajdonság megváltoztatását vonja maga után.
              @V*@N  Esemény--mûvelet  kapcsolat:  esemény bekövetkeztekor
          végrehajtódik a mûvelet.
              @V*@N   Tulajdonság--mûvelet:   az   attribútum    értékének
          megváltozásakor végrehajtódik a mûvelet.
              @V*@N  Esemény--tagfüggvény:   az  esemény   bekövetkeztekor
          meghívódik egy C++ osztály tagfüggvénye.
              @V*@N      Tulajdonság--tagfüggvény:      az      attribútum
          megváltozásakor meghívódik a tagfüggvény.
              Kapcsolatoknak   lehetnek   még   paraméterei   (szintén
          kapcsolat   formában   egyébként),   illetve   használhatunk
          speciális mechanizmusokat is a megfelelô hatások elérésére.
              A  kapcsolatoknak  különbözô  színû  nyilacskák felelnek
          meg, a kapcsolatok irányát pedig az jelzi, hogy be  vannak-e
          színezve  a  nyílhegyek.   Egy  egyszerû  példa:   egy  gomb
          @KbuttonClickEvent@N eseményét  összeköthetjük az  ôt tartalmazó
          ablak   @Kclose@N   akciójával.   Ennek   nyilván   az   lesz  a
          következménye,  hogy a  gomb megnyomása  után becsukódik  az
          ablak (példa az esemény--mûvelet kapcsolatra). Ennél  sokkal
          bonyolultabb   mechanizmusok  is   létrehozhatók,  a   többi
          kapcsolattípussal, illetve saját C++ kóddal.
              A  vizuális  programozás  másik  fele  --  nevezetesen a
          @Krész@Nek elhelyezése a munkaterületen -- nagyjából megfelel  a
          többi  ilyen  programozói eszköz  tudásának.  Több csoportba
          osztott   palettáról   választhatjuk   ki   az  elhelyezendô
          elemeket, az elemek egymáshoz képesti elhelyezkedését  pedig
          a felsô  eszközsorbeli gombokkal  szabályozhatjuk: egymáshoz
          illeszthetjük  a  kiválasztott  elemek  szélét, egyenletesen
          szétteríthetjük  ôket   egy  területen,   illetve  egymáshoz
          igazíthatjuk   méretüket.   A   Smalltalk   alapú  VisualAge
          Motif-szerû   osztálykönyvtárából   megszokott    futásidejû
          elhelyezkedés-kiszámítást sajnos nélkülöznünk kell. Ez nekem
          elég  nagy  kellemetlenségnek   tûnt  --  cserébe   a  többi
          beállítható  opcióból  sokkal több  van,  jóval kézenfekvôbb
          lett néhány attribútum elhelyezése.
              Összességében  a   vizuális  programozói   felületnek  a
          lassúságán kívül nincs sok hibája, jól használható, a  többi
          C++ alapú ilyen eszköznél sokkal jobb (bár  használhatóságát
          erôsen csökkenti, hogy csak OS/2-es változata létezik.)


          @VA ""hagyományos" környezet@N

              Az élet persze nem csak kattintgatásból áll --  mondanák
          néhányan --, nem hozhatók létre komoly programok csak ikonok
          ide-oda húzogatásával. Bár  az utóbbi állítás  elfogadásával
          mintegy  elzárkózunk   a  probléma   mélyebb  megismerésétôl
          (jogosan, hiszen  ennek a  cikknek más  a célja), idôlegesen
          tekinthetjük majdnem igaznak. Ez az elv is, meg a  VisualAge
          valósága is -- jelesen, VisualAge alatt valóban nem  hozható
          létre  nagyobb  alkalmazás  csupán  kattintgatással  -- arra
          ösztönöz minket, hogy megismerjük, milyen más  lehetôségeket
          rejt magában a rendszer.
              Tartalmaz   elôször   is   egy   kitûnô,   programozható
          szövegszerkesztôt, rengeteg  beépített lehetôséggel.  Szinte
          mindent tud, amit egy rendes programozói szövegszerkesztônek
          tudnia kell -- amit pedig nem, arra program írható. A Visual
          Buildertôl és  a C++  fordítótól eltekintve  ez a  program a
          rendszer  egyik   legfontosabb  része,   ezt  használjuk   a
          legtöbbet.
              Az elkészült kód  vizsgálatára is találunk  eszközöket a
          VisualAge  C++-ban:  nyomkövetôt, programstruktúra-böngészôt
          és teljesítményelemzôt.
              A  nyomkövetô program  nagyjából mindent  tud, amit  egy
          ilyen  környezetben  futó 3GL  nyomkövetô  programnak tudnia
          kell. Az alapfunkciókon kívül a tárgykód szintû nyomkövetést
          is  megkönnyíti,  teljes  regiszterlistával  (a lebegôpontos
          koprocesszor  regisztereivel   együtt)  és   a  forráskódhoz
          keverhetô assembly tárgykóddal.
              A böngészô  és a  teljesítményelemzô program  is hasonló
          színvonalú. A  puding próbája  persze az  evés, az  eszközök
          csínját-bínját legjobban használatuk során lehet megismerni.
              Összefoglalásképpen:     a     VisualAge     smalltalkos
          változatának eleganciáját sajnos nem éri utol ez a termék --
          persze  ez  már  a C++  természete  miatt  szinte lehetetlen
          vállalkozás.  Cserébe  kárpótolhat  minket  a  létrejött kód
          hatékonysága -- messze nem igényel annyi erôforrást, mint az
          a  változat.  Jól   sikerült  integrálni  a   sok  különbözô
          fejlesztôi  eszközt   a  WorkFrame   révén.  Nagyon   jók  a
          kiegészítô       programok       (böngészô,      nyomkövetô,
          teljesítményelemzô), amelyekre persze nem volt külön szükség
          a smalltalkos verzióban (új kódot csak böngészôkkel  tudtunk
          a  rendszerhez hozzáadni,  teljesítményelemzésre a  rendszer
          alapvetô erôforráspazarlása miatt szinte alig volt  szükség,
          teljesítménykritikus kódot pedig szinte lehetetlen VisualAge
          Smalltalkban írni).
              Mostanában nagyon divatosak a vizuális  programfejlesztô
          rendszerek.  Még   az  IBM   sincs  könnyû   helyzetben,  ha
          versenyképes  terméket  kíván  létrehozni.  A  VisualAge C++
          kiemelkedik   a    mezônybôl   átgondoltságával,    kellemes
          osztálykönyvtárával, jól használható eszközeivel. Két hibája
          van.  Az  egyik a  lassúsága:  memória- és  processzorigénye
          szinte  kielégíthetetlen.  Ez  az  elkészült  kódon  azonban
          egyáltalán  nem látszik,  a fejlesztôknek  pedig legyen  sok
          pénze  vagy  sok ideje.  A  másik, súlyosabb  hibája  -- ami
          tulajdonképpen két alhibából tevôdik össze: kevés platformot
          támogat  --  csak  OS/2  alatt  mûködik,  és  a  használható
          adatbáziskezelôk köre  is szûk.  Kijavítva ezeket  a hibákat
          (fôleg  az  utóbbiakat)  sokkal  hatékonyabbá  válna  ez  az
          eszköz.

          @KÉder Géza@N

          @<9512\HAGY.GIF>■■@N  A ""hagyományos" módszer: munka az editorral

          @<9512\DEBUG.GIF>■■@N  Munkában a debugger

          @<9512\GOMBA.GIF>■■@N  Egy rész a vizuális környezetbôl: a Composition Editor